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ABSTRACT 

ERP (Enterprise Resource Planning) systems have 
increasingly been developed and integrated with other 
internal and external systems. This paper contributes 
to the field of enterprise systems integration by 
clarifying the concept of integration in the context of 
ERP systems. We investigated integration obstacles 
during ERP development in 5 large organizations 
through theme-based interviews. Besides considering 
integration as purely technical challenge, our findings 
reveal the other perspectives of integration. In total 31 
environmental, technical, managerial, and 
organizational integration obstacles were identified 
from empirical data and further mapped with 13 ERP 
challenge categories derived from the literature. Our 
findings reveal that integration barriers are related to 
all 13 categories of ERP challenges. This indicates 
that integration should not be a separate project from 
ERP development. Identifying the integration 
obstacles is necessary for practitioners to develop 
counteractions to enterprise integration problems. 

1. INTRODUCTION 

Companies must improve their business procedures 
and processes in order to remain competitive. They 
must also share their in-house information with their 
suppliers, distributors, and customers [27], This 
information should be timely and accurate. 
Companies adopt Enterprise Resource Planning 
(ERP) systems to fulfill these objectives. ERP systems 
are information systems that integrate different 
business functions [5,11]. Companies spend 
significant amounts of their IT budget in ERP 
installations and upgrades [10,11]. However, ERP 
projects are associated with considerable problems 
and high failure rates [19,33], Besides technical 


aspects, ERP implementation imposes numerous 
social and organizational issues [10]. 

Implementing an ERP system does not guarantee the 
integration of the organization, as ERPs need to co¬ 
exist with other enterprise applications and systems. 

2. Background 

ERP systems are configurable Information System 
(IS) packages that aid in accomplishing the 
business [3 9]. Mainstream ERP studies in the realm of 
integration address the approaches to achieve 
integration [25,26] or implementing ERP as a way to 
achieve integration [16,18] However, it has been 
identified that integration in the context of enterprise 
systems is surrounded by confusion [6,17,25]. 

With this study, we aim to increase the understanding 
of the nature of integration in ERP development that 
is often overlooked in research. To achieve this, we 
employ both literature and empirical data from 52 
interviews in 5 large enterprises. This paper addresses 
the following research questions: 

RQ1: What issues hinder integration? 

RQ2: How do issues hindering integration relate to 
general ERP development challenges? 

In the remainder of this paper, we first review the 
literature for this research. After that, we explain the 
research approach and present the results. Before 
concluding the paper, we discuss about our 
contributions and lessons learned based on the 
findings goals by facilitating real-time planning, 
production, and customer response [20,32], They 
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consist of different modules, such as sales, 
production, human resource, which are interconnected 
to enable the exchange of business data across 
different organizational units [12]. ERP systems offer 
a central repository for enterprise data and promise 
reduced data redundancy, increased supply chain 
efficiency, increased customer access to products and 
services, and reduced operating costs [13,29], 

These benefits are not easily accomplished. It has 
been estimated that 90% of ERP implementations fail 
to provide all the desired business benefits [28], 
Several distinct characteristics make ERP projects 
troublesome. The implementation involves multiple 
organizations and stakeholders that need to interact 
and communicate. This makes the implementation 
prone to errors and misunderstandings [35]. 
Moreover, there is the constant dilemma to decide, 
should the system be customized or should the 
existing ways of working be altered [4], Due to the 
role of ERP systems as a backbone for enterprise 
integration, they need to co-exist with other enterprise 
systems [38], Interconnections with internal and 
external systems is a necessity and a crucial part in 
ERP development [15]. When replacing the existing 
legacy systems with the ERP, usually the migration 
process involves the implementation of temporary 
interfaces between systems, which can be expensive 
and time consuming [40]. In general, ERP systems 
have limited capability in integrating with other 
systems [5]. 

Due to the challenging nature of ERP projects, a 
considerable amount of literature has focused on 
critical factors in these projects [2,9,14,28,30,31,36], 
These studies have not widely addressed integration 
issues. Integration is mainly seen as something that is 
finished during the project phase of the system 
development, such as in terms of data management 
between legacy systems. However, instead of being 
an outcome or an activity occurring during a single 
phase, in the context of ERP systems, integration is a 
continuous activity conducted during the whole life 
cycle of the system [22], 

Furthermore, the term integration is generally a 
concept surrounded by a fair amount of confusion 
[6,17,25], For instance, some authors in the literature 
tends to consider integration as a project outcome or 
as a technical feature [6]. We understand ERP system 
integration as a process during the ERP system life 
cycle, in which interfaces and interconnections 
between the ERP and other internal and external 


systems are built and managed as a collaborative 
effort conducted by different organizations and 
stakeholders involved in development. With this 
study, we want to better understand the nature of this 
activity by examining the issues that hinder it. 

3. Research process 

This research was designed as a qualitative, thematic 
study. We deemed this approach to be suitable when 
approaching the research problem of enterprise 
system integration because besides its technical 
nature, it includes organizational and managerial 
issues [3]. The main instrument in the data collection 
was theme-based interviews in five companies. The 
companies were large - their sizes ranged 1000 to 
30000 employees. To analyze the data we employed a 
qualitative inductive analysis, in which we identified 
new kind of occurrences in the data and classified 
them with codes. This is also called “open coding” [7] 
in grounded theory. According to [34] 

“qualitative inductive analysis generates new 
concepts, explanations, results, and/or theories from 
the specific data of a qualitative study. ” 

3.1. Data collection 

To conduct this study, both literature and empirical 
data were employed. We carried out two rounds of 
theme-based interviews. In the first round, we 
gathered data from three organizations (Case A, B, 
and C) in the period from February 2013 to May 
2014. These interviewees included stakeholders from 
client organizations, the vendors and third parties, 
such as a middleware vendor and offshore 
departments. No strict interview protocol was used, 
but instead, the questions focused on general 
challenges in ERP development. More detailed 
questions were asked based on the answers. Total of 
45 interviews with an average duration of one hour 
were made in the first round. In the second round, we 
gathered data from three organizations (Case A, D, 
and E) in May and June 2014. In total, 9 experts were 
interviewed, with the average duration of the 
interviews being 1 hour and 15 minutes. The question 
set included technologies, standards, organizations 
and stakeholders dealing with integration issues. We 
consider second round as our main dataset in this 
study since its focus was on integration issues while 
the first round data served more as supportive 
material. Table 1 lists the case organizations and the 
roles of interviewees. 
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Table 1 Information about Case organizations and interviewees 


Cases 

Size and industry 

ERP systems 

No. of 
interviews 

Role of 
interviewees 

1 st Round 

A 

Large & global 

manufacturing enterprise 

with 30000 employees 

Tailored system for sales 
and logistics SAP ERP for 
administrative processes 

17 

Different roles 

representing the 

client organization, 
the vendor and 
third party 

organizations 

B 

Large & global service 
provider in retail business 
with 1000 employees 

Tailored ERP system for 
retail business processes 

16 

C 

Large and global 

manufacturing enterprise 

with 20000 employees 

Tailored ERP system for 
the raw material 

procurement 

10 

Different roles 

representing the 

client organization 

2 nd Round 

A 

Large & global 

manufacturing enterprise 

with 30000 employees 

Tailored system for sales 
and logistics SAP ERP for 
administrative processes 

6 

Business-IT 
negotiator IT 

manager of 

business area 

Manager of E- 
business and 

integration Head of 
E-business and 

integration 

Business support 
manager of a 

business area 

Director of 

business process 
development 

D 

Large and global 

manufacturing and service 
provider enterprise with 
5000 employees 

Tailored ERP system 

2 

Head of IT 

department 

Manager of IT and 

enterprise 

engineering 

E 

Large and global 

manufacturing and service 
provider enterprise with 
1600 employees 

A system based on Oracle 
products 

1 

Head of systems 
analyze & design 


The ERP systems in case organizations were in 
different phases in their life cycle. In Case A, the 
tailored system had been in use and development for 
20 years. During the interviews the retirement phase 
of the system had begun as the company was 
considering replacing it with a SAP ERP. The ERP 
system in Case B was in the middle of the 
implementation phase. The system in Case C was in 
the post-implementation phase, currently being 
deployed to a new business location in another 
country. Case D started the implementation of a new 
ERP system in 2012 and has been since improving the 


business processes and enhancing the system. Case E 
was about to change their ERP system from Informix 
to Oracle. Most of the transition had been done but 
few systems were needed to be changed to Oracle. 

3.2. Data analysis 

We extracted and identified integration obstacles from 
the transcribed interviews. Three researchers used the 
principles of open coding [8] to label the data and to 
find the integration obstacles from the primary data 
set. Due to the fact that each researcher makes his/her 
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own interpretations from the data, it was necessary to 
discuss and compare the identified obstacles. After 
several brainstorming sessions, a list of 31 integration 
obstacles was constructed, with six obstacles not 
previously mentioned in the literature. 

To have a comprehensive view on the integration 
obstacles and their relationships to general ERP 
development challenges studied in the literature, we 
used the classification of ERP development 
challenges by [1]. In addition, we reviewed seven 
literature reviews on ERP development challenges 
[2,9,14,28,30,31,36] and modified the original 
classification. This comparison produced in total 13 
categories of ERP development challenges. For 


example, in the literature category “Network and 
communication” concerned with “boundary crossing 
activities” and issues related to “consultant and 
vendor companies” was divided into “Inter- 
organizational environment” and “Communication 
and coordination”. 

Inspired by Themistocleus [37] and Shaul & Tauber, 
[36] we further classified the 13 categories into four 
main themes: Environmental, Technical, Managerial, 
and Organizational obstacles. Table 2 presents this 
categorization. We then mapped the integration 
obstacles extracted from the data to the general 
categories of ERP challenges found from literature. 


Table 2 Main themes, literature categories and integration obstacles 


Main themes 

Categories of general ERP challenges from the 
literature 
[2,9,14,28,30,31,36] 

Integration obstacles 
derived from data 

Cases 

Environmental 

obstacles 

Intra-organizational environment 

Issues related to organizational culture as well as 
organization’s experience on ERP projects 

Complicated end product 

A 

Inexperience on integration 
projects 

A, E 

Heterogeneous operating 
environment 

C 

Different strategic interests 
of business units 

A 

Inter-organizational environment 

Issues related to external environment such as 
conflicts 

between the organizations, poor management of 
partnerships with these organizations and 
underperformance 
of either vendor or consultant 

Sanctions in licensing 

E 

Competitors taking new 
technologies into use 

A, C, E 

Failing to commit customers 
in integration projects 

A, D 

Discovering a way to satisfy 
customers by integration 

A, E 

Technical 

obstacles 

ERP-product selection & implementation 
strategy 

Issues regarding selecting and comparing different 

ERP 

products 

Selecting unsuitable 
integration technologies 

A 

Troublesome management 
of integration 
product licenses 

A, E 

ERP system characteristics 

Issues related to the lack of ERP system’s quality 

Design flaws in ERP system 

A 

ERP system’s 
incompatibility 

A 

IT-infrastructure & legacy systems 

Problems in integrating the ERP system with other 
systems 

and converting the data between the systems as 
well as 

managing the master data 

Characteristics of 
integrative systems 

A, B 

Complex systems landscape 

A, D 

Troublesome migration 

A, B 


@ IJTSRD | AvailableOnline@www.ijtsrd.coml Volume-2 | Issue-3 |Mar-Apr2018 Page: 2435 






















International Journal of Trend in Scientific Research and Development (IJTSRD) ISSN: 2456-6470 



ERP software development & configuration 

Issues dealing with requirement specifications 
definition and 

changes, system configuration, and software 
development 

tools and methods. Also, issues related to 
troubleshooting 

and functional testing of the software 

Poor evaluation of 
integration requirements 

A 

Slow development process 

A, B, C 

Inadequate testing of 
integration 

A 

Lack of knowledge on 
integration 

A, E 

Managerial 

obstacles 

Business visioning & planning 

Issues in creation of the business case for the 
system, setting 

up business goals and justifying the ERP 

acquisition 

financially 

Cost cutting hindering 
integration projects 

A 

Insufficient identification of 
business needs & 
evaluating the benefits of 
integration 

A 

Organizational management & leadership 

Issues related to top level management's 
involvement, 

capabilities and actions in the project 

Top management does not 
understand 

Integration 

A, C, D 

Top management does not 
support integration 

A, D, E 

Lack of company-wide 
policies for integration 

A, D 

Project management 

Issues regarding the project scope, responsibilities, 
and 

resources. Also issues related to crisis and 

expectations 

management 

Troublesome management 
of integration 

Projects 

A 

Project team & human resources 

Challenges related to structure and composition, 
and skills 

of the people in the project team. Also issues 
related to 

empowerment, motivation and incentives 

Lack of integration experts 

D 

No dedicated persons for 
integration 

D 

Quality management & evaluation 

Challenges related to measuring the performance 
and 

acceptance of the system 

Not measuring integration 
projects 

A 

Organizational 

obstacles 

Change management 

Issues related to business process re-engineering, 
training 

and education. Also factors related to 
misunderstanding of 
the change caused by the system and its 
implication to 

organizational culture, personal factors and 
political issues 

The need for comprehensive 
training 

A, C, D 

Personnel change resistance 

A 

Communication & coordination 

Factors related to communication style, coverage 
and 

planning. In addition, issues related to knowledge 
management and unsuitable communication tools 

Lack of collaboration 

A, D, E 


@ IJTSRD | AvailableOnline@www.ijtsrd.coml Volume-2 | Issue-3 |Mar-Apr2018 Page: 2436 






















International Journal of Trend in Scientific Research and Development (IJTSRD) ISSN: 2456-6470 


4. Results 

We mapped the identified 31 integration obstacles 
into the ERP challenges found from literature. Table 2 
shows the categorization. The next sections explain 
the integration obstacles derived from data. 

4.1. Environmental obstacles 

In Case A, because of the complicated product of the 
company, complex structures were needed to store 
product information in the ERP systems. This made 
some of the integration projects difficult. For instance, 
customers faced difficulties when defining the product 
variables in their systems, as mappings and 
conversions between different ERP systems required 
significant efforts. In Cases A and E facilities 
inexperience on integration projects and low 
maturity level of organization hindered integration. In 
Case A, some facilities did not have previous 
experience on ERP system deployments, which 
hindered the roll-outs. On the other hand in Case E, 
organizational immaturity was seen as a major barrier 
for integration. The differing readiness for integration 
in organizational units was highlighted: “We have 
75% integration in our supply and distribution 
department but we only achieved 30% integration in 
after sale service department because the maturity 
level of this section was very low ” -Case E, Head of 
systems analyze & design 

Case C encountered difficulties due to the 
heterogeneous operating environments. The misfit 
between the ERP system and the new operating 
environment was learnt the hard way. As the ERP 
system was to be deployed to a new business location 
in another country, the drastic differences between the 
business processes and practices forced the company 
to consider implementing a new instance of the 
system which would then have to be integrated with 
the ERP system currently in use. Initiating the 
deployment project to this environment was 
eventually cancelled. 

The environment was characterized as being “ 20 
years behind” the focal country and being a 
“ conservative, old-fashioned field”. 

In Case A, different strategic interests of business 

units introduced conflicts in ERP development. A 
development need that other unit considered 
important might not be an interest for the other. As a 
consequence, integration projects were prioritized 


differently, which increased the development time, 
causing the other units to wait for the needed features. 

Besides the intra-organizational environment, 
integration can also be hindered by external forces. 
For example, in Case E due to the political sanctions, 
licensing caused problems. An ERP provider refused 
to sell the required licenses to the company. 
Therefore, the company bore financial loss, having 
already trained and prepared to adapt the specific ERP 
system. Eventually, the company was forced to 
change the ERP provider. 

In Case A, the possibility of competitors taking new 
technologies into use might cause them to re¬ 
consider their existing integration solutions. Similarly 
in Case C, competitors were planning to take a new 
domain standard into use. This caused pressures for 
the company. Possibly it had to abandon the 
application logic developed in-house and re-develop 
the system interfaces to comply with the new 
standard: 

“If we get involved in [the standardization project], it 
would mean that part of the ERP system would be 
outsourced to an external service, which would be 
integrated with the system ” -Case C, Client 
organization representative 

Also in Case E, the pace of environmental change 

was mentioned as a matter setting pressures on 
integration. It was mentioned that it is difficult to 
“attune with those changes ”. 

In Cases A and D customers’ loyalty and 
commitment in integration projects were 
considered as an obstacle. Customers facing 
organizational changes could stop the ongoing 
integration initiatives in Case A. On the other hand, in 
Case D, small customers sometimes lacked the needed 
knowledge on integration, which made it more 
difficult to cooperate with them. In Case B, it was 
mentioned that as several business partners are 
involved in the ERP project, sometimes coordination 
issues emerge as it is necessary to wait partners to 
complete certain operations before the development 
can continue. 

Cases A and E looked for tighter integration with 
customers. Instead of responding to customers’ needs, 
companies were discovering ways to better satisfy 
their customers, trying to “make it easy to buy from 
us” and implement new solutions “even before they 
come to us and ask for it”. This was considered 
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difficult. For instance, in Case A, mobile applications 
for customers were considered in order to achieve 
tighter integration with customers. 

4.2. Technical obstacles 

In Case A, selecting unsuitable integration 
technologies caused the system architecture to be 
redesigned in the early phases of implementation. 
According to the middleware provider, not enough 
attention was paid on the selection of the base 
technologies of the system. In addition, troublesome 
management of integration product licenses turned 
out to be an obstacle in Case A and E. Knowing the 
limitations of licenses and avoiding getting fines or 
sued by the product providers was emphasized, “as 
huge costs are always involved in license 
management ”. 

In Case A, certain architectural decisions caused that 
the facilities used different codes in system messages 
sent from the facility systems to the ERP system. This 
later led to problems when trying to collect the same 
information from all the facility systems: 

“Because all [facilities are using] different codes and 
that's a nightmare [...] when you want to report 
something or when for example our sales offices who 
are using [the ERP system], for all the [facilities]. 
They actually see very different data for them, 
because of the different codes which we have allowed 
in our 

ERP. ” -Case A, Business support manager 

This was identified as one of the design flaws in the 
customized ERP system that would not be able to be 
fixed during the life cycle of the system. In addition, 
by having a vendor specific message format in the 
system, integrating the ERP system with external 
systems was considered challenging. Because of 
different levels of standards being used internally and 
externally, the ERP system incompatibility 
challenged integration with external systems. 

In Case B, characteristics of integrative systems 
introduced a fundamental obstacle of integration. The 
data formats of two systems were different and the 
older system could not handle specific data types. 
Similarly in Case A, the factor affecting the easiness 
of rollouts was said to be dependent on the 
characteristics of the facility system in question. 


Complex systems landscape where integration takes 
place was one aspect that made integration difficult. 
In Case A, the organization was dealing with a huge 
number of different systems. Business-IT Negotiator 
of Case A stated that it is difficult to “reach the ideal 
world” as the landscape of system “ evolves 
constantly ” due to the organizational changes. An 
integration project that required exchanging of 
messages between three ERP systems, was considered 
as “a mission impossible”. A project in which an 
invoice was to be sent from one office to another 
through several system, had been initiated four years 
ago but was still ongoing during the interviews. 
Furthermore, the increased complexity hindered the 
information retrieval from the logistics systems: 

“[When getting information from logistics systems] 
there are not only delays, there are total black outs. 
We don't always get the information. [Then we] get 
the customer calls: ‘Where is my order? It should be 
here now’” -Case A, Director of business process 
development 

Troublesome migration was encountered in Cases A 
and B. During migration, data conversions from 
legacy systems, master data management and parallel 
run of systems are needed. In Case A, migration from 
the old system to the new one took years. In Case B, 
using two systems simultaneously was considered too 
difficult from the end-user’s viewpoint and because of 
this, the new ERP system was not deployed to all the 
sales offices. Major technical problems were 
encountered when running the two ERP systems in 
parallel. The data transfer between the two systems 
was unreliable, due to insufficiently designed 
interfaces: 

"The problems emerged because the interface was the 
problem. The data might have been accurate in the 
new system [...] but they did not manage to make the 
logic between two of their applications bullet proof. 
[...] the data that came to our system was somehow 
corrupted" -Case B, Representative of Finance 

Transferring the master data from the old system to 
the new one was seen problematic in Cases A and B. 
In Case B, it was claimed that the parent company 
“did not have a capability for master data ”. 
Moreover, different policies for master data were used 
in group and national levels of the company. 

The slow development process turned out to make 
integration more difficult. In order to cut down the 
development costs caused by a customized system, in 
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Cases A and C the vendor had offshored the 
development to remote locations. Because of this, it 
took a long time until new feature requests would 
realize as new features in a system: 

“If the development on our side is something which is 
then related to [our ERP], then it takes time [...] then 
we are really talking about six seven eight months. ” - 
Case A, Manager of e-business and integration 

The slow development process was also highlighted 
by a representative of Case C, who emphasized that 
the development process should be made faster. 

Poor evaluation of integration requirements was 

sometimes hindering integration projects. In Case A, 
it was specifically highlighted that the need for 
integration and testing of it may appear suddenly, if 
the development is done without establishing separate 
projects and the requirements for integration are not 
comprehensively investigated. Similarly, inadequate 
testing of integration was mentioned as a major 
obstacle in integration projects. In Case A, a sudden 
need for testing appeared due to the lack of 
inappropriate planning. Resources that were not 
initially allocated for the project were needed: 

“It is not realized that [integration] requires a lot of 
testing [...] the resources that are then used, are not 
specifically allocated for the project but instead 
internal resources. But then, what are their skills and 
motivation? How it is being documented that 
something has been tested?” -Case A, Business-IT 
Negotiator 

Lack of knowledge mentioned as an obstacle for 
integration. Integration projects that were performed 
for the first time with no previous experience on 
similar projects were considered challenging in Case 
A. For example, having a customer using SAP 
involved for the first time was considered painful. 
Similarly, if integration would require an 
implementation of a totally new business process with 
new messages, needed more effort that the projects in 
which already existing knowledge could be utilized. 
In Case E on the other hand, the lack of 
documentation about integration frameworks and 
technologies caused a big halt in the project as the 
needed information was gathered from different 
places. 

4.3. Managerial obstacles 


Another issue hindering integration in Case A was the 
constant development cost cutting. Because of this, 
fewer resources were available for developing and 
extending the system further. This caused some of the 
integration projects to be postponed. According to the 
current trends and the changed role of the ERP system 
from a back-end tool to a tool of salesmen that 
interact with customers on the field, the company was 
planning to build mobile applications to enable end 
users and customers to access the ERP system from 
remote locations. This was, however, considered too 
expensive, and the initiative was dropped out due to 
the cost saving: 

“We have been talking about [the mobile interfaces of 
the system] and made some pilots, but they haven’t 
gone further [...] they are probably the first thing to 
drop out when cutting down the development costs. ” - 

Case A, vendor, Lead software developer 

Cost cutting was also considered as a major barrier 
when developing the business processes further 
through integration, it was said that there is “a lot of 
unattached potential but no willingness to invest ”. 

Identification of business needs and evaluating the 
benefits of integration was mentioned to be 
burdensome to integration projects. According to the 
Enterprise Architect in Case A, the challenging phase 
in some of the integration projects was the evaluation 
of costs and the business benefits. The business-IT 
negotiator stated that evaluating the size and the 
complexity of integration projects were difficult, and 
the significance of integration was “mainly 
underestimated”. This led to resource allocation 
problems in these projects. Due to the lack of internal 
collaboration and organizational silos, certain cross¬ 
checking and verification (i.e., by finding out which 
part of the system the development would have an 
impact) was sometimes omitted when developing new 
functionality. This also led to wasted resources. 

In cases A, C and D, the top management sometimes 
lacked the understanding of integration. In Case A, 
the management had too high expectations what could 
be achieved by integration. Similarly in Case D, 
management lacked the understanding on integration: 

“The high management cannot really realize the 
benefits of integration. It is hard to convince them 
how an integration project can benefit the 
organization. In words they say ‘Ok, let’s do the 
integration project ’ but when it comes to practice and 
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reality they withdraw” -Case D, Manager of IT 
department and organizational engineering 

Also, sometimes management was unwilling to 
participate in integration projects which caused the 
project to lack the management support. In Case C, as 
the system was deployed to the new operating 
environment in different nation, local manager’s 
attitude was not supportive and the project lacked 
leadership. 

The lack of top management’s support in 
integration projects came up in Case A and D. The 
constant changes of top management terminated the 
on-going customer integration projects in Case A and 
it took years to re-establish them. Similarly in Case E, 
changes in top management “brought chaos and even 
terminated the existing integration projects”. The 
extent to which the top management prioritizes 
integration was seen crucial in Cases A and E. 

Due to the Lack of companywide policies for 
integration, difficult integration scenarios were 
encountered in Case A. When the ERP system was 
under the busiest implementation, the policies of 
individual facilities had an impact on how the 
integration between the ERP system and a 
manufacturing execution system in question was 
done. This led to a problem when querying 
information from the facilities as the quality of the 
retrieved information was varying. It was suggested 
that the common rules should have been decided in 
advance to prevent this, and there should be “a 
dictator”, when defining these rules. Similarly in 
Case D, due to the fact that different enterprise 
systems were developed separately, the end users had 
to separately log in to each system. It was suggested 
that there should be a single sign in option instead to 
avoid the manual work and redundancy. Difficulties 
in integration project management were 
experienced. Allocating resources for these projects 
and keeping them in budget and schedule were not 
easy. Some of the development projects were not 
done in a systematic manner as projects. Instead, “the 
one who has the money” could initiate development 
activities, without negotiating with other parties. 
These projects encountered unexpected issues with 
resources. A representative of Case A highlighted the 
attitude towards integration: 

“The biggest challenge is to evaluate the size and 
complexity of the project. I state that the significance 
of integration is mainly underestimated [...] is it just 


stated that the technology and tools are clear, ‘this 
cannot be a big issue’” -Case A, Business-IT 
Negotiator 

Convincing the top management and developers about 
the value and importance of software testing in 
integration projects was mentioned as a considerable 
challenge for project managers. 

Case D faced resourcing issues due to the lack of 
integration experts. Lack of personnel with skills on 
middleware and SOA (Service-Oriented Architecture) 
hindered integration projects. It was stated that 
suppliers familiar with specific technologies, such as 
BizTalk or Oracle “can’t really implement anything 
themselves”. Similarly, selecting of the supplier was 
said to be “risky because of their limited knowledge ”. 
In addition the company had no dedicated persons 
responsible for integration. Instead, managing the IT 
architecture and doing integration were considered as 
additional works which reduce the pace of integration: 

“When you are integrating systems using middleware, 
we should unify some architectural basics. Sometimes 
you need to re-engineer the tasks. This work conflicts 
with our routine work. We cannot stop this ‘moving 
train ’ to do integration. ” -Case D, Manager of IT 
department and organizational engineering 

Not measuring integration projects to evaluate 
whether or not the desired business goals are met, was 
considered problematic. Case A was using 
measurement to evaluate how much the certain 
business integration solutions were used by different 
business units. However, in integration projects, 
measurements were not established. Also, if an 
integration project was carried out in a non-systematic 
way, there were no proper quality management 
practices in place. Measuring the performance of 
integration project on customers’ side and evaluate 
the value of customers’ satisfaction was considered 
“difficult if not impossible ” since there were no 
similar access to customer’s resources and systems in 
a similar fashion as own internal systems. 

4.4. Organizational obstacles 

Personnel resistance to change was described as an 
obstacle that comes with integration in Cases A and 
D. The interviewees highlighted the need to carefully 
explain to the related personnel what the change 
means in practice: 
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“You should assure them that changes that have 
come up with integration does not mean that you are 
going to lose your job” -Case D, Head of IT 
department 

Case C also faced personnel resistance to change and 
their unwillingness to take the new system into use 
when deploying the system to a new geographical 
location: 

“They didn’t really want to have that system [...] or 
even willing to develop it to fit their needs in 
general. ” -Case C, Client organization representative 

In addition, in Case A, change resistance was 
identified as a major barrier that terminated the 
attempts trying to simplify the complex systems 
landscape: 

“System-specific groups have been established there 
[...] they do not have the desire to make this (ERP 
system landscape) any simpler. And all the 
external players who enter this field, are excluded in 
one way or another. ” -Case A, Business-IT 
Negotiator The importance of the need for 
comprehensive training programs were considered 
essential when trying to mitigate the change resistance 
caused by integration. The interviewee from Case A 
mentioned the necessity of training when deploying 
new systems, considering it as a “ major part of the 
ERP project”. Similarly, integration with customers 
created a need for training due to the changed roles of 
the persons dealing with customers. 

Lack of collaboration made the coordination of 
integration activities more difficult in various ways. In 
Case D, lack of teamwork was said to be a major 
inhibitor of integration. In Case A, despite the fact 
that the business units had different strategic interests, 
the representative of Sales noted that the services 
needed from the ERP system can still be the same. 
Because of lack of cooperation, duplicate 
development was sometimes done, which led to 
increased costs: 

“Better tools for sales prediction may be an essential 
development requirement for both of these big 
business areas, and still these things may not be 
handled together. [...] Instead of doing one joint 
project, we may do two in parallel. ” -Case A, 
representative of Sales 

The lack of inter-departmental cooperation caused 
that certain parts of the organization could not 


benefits from the services already developed in the 
other parts of the ERP system. Similarly in Case E, 
the communication between branches in different 
cities was considered as limited. Using improper tools 
added manual work, suggesting that the 
communication was not carried out in the desirable 
manner. 

5. Discussion 

The main contribution of this study is to increase 
understanding of integration in the context of ERP 
systems. The current literature on ERP challenges 
mainly focuses on the challenges encountered during 
the main ERP project and mostly highlight the 
technical issues when interfacing with legacy systems 
[2], incompatible existing systems [30], and data 
management and conversion [36], Besides 
considering integration as purely technical challenge, 
our findings reveal the other (environmental, 
managerial and organizational) perspectives of 
integration. The identified integration obstacles are 
interrelated with all the 13 categories of ERP 
challenges derived from literature. This shows that 
integration should not be viewed as a separate task 
that is finished during an ERP project. Instead, 
integration is tightly coupled with ERP development 
and it is a continuous effort requiring attention during 
the entire life cycle of the system. We found some 
integration obstacles that have not been widely 
covered in the ERP literature before, such as political 
sanctions, management of product licenses, lack of 
measurements for integration projects, discovering a 
way to satisfy customers by integration, lack of 
previous experience on integration projects and lack 
of company-wide policies for integration. 

Integration challenges and barriers in enterprise 
application integration and in e-govemment have been 
studied, e.g. in [21,23,37]. Themistocleus (2004) 
identified 12 application integration barriers. Our 
findings can be considered as an extension of this list. 
Similarly, we found that resistance to change, 
training, and lack of technical skills as barriers for 
integration. However, we did not see the costs as a 
major barrier. Another study about critical factors of 
adopting EAI revealed technical, organizational and 
environmental dimensions that majorly impact 
integration in a health care environment [21], The 
authors found out that the top management support 
did not have a high impact on the EAI integration. 
We, however, found top management support as a 
critical barrier in three of our case organizations in 
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manufacturing domain. Similar to healthcare domain, 
the external pressure from competitors appeared to 
introduce integration challenges in three of our case 
organizations in manufacturing domain. 

5.1. Lessons learned 

It is possible to derive from the findings some 
important considerations for practitioners to 
overcome the obstacles in integration: 

Integration should be regarded as a systematic and 
well planned activity that involves multiple systems, 
and stakeholders. Separate programs or projects are 
always needed to be established. 

Dedicated expertise is needed. There should be 
stakeholders with a full-time responsibility of 
integration issues. Coordination and communication 
among the stakeholders is crucial. 

Integration projects need to be managed from 
different levels. Besides the top management support, 
project and quality managers as well as change 
management is needed 

Due to the complex nature of integration, it is 
important to maintain the architectural descriptions of 
the interconnected systems to facilitate the 
identification of integration needs and requirements. 

Corporate-level integration strategies are needed to 
ensure that integration is aligned with organizational 
goals 

5.2. Limitations 

This study has its limitations. As in all qualitative 
studies, it is also impossible to make direct statistical 
generalizations from these five companies. We, 
however, believe that the classification of integration 
obstacles is valuable information to other researchers 
with similar objectives and also to practitioners that 
wish to manage integration in their organizations. 
Instead of statistical generalization we consider our 
generalization as theoretical [24], where we formed 
abstract categories out of specific and concrete 
observations. Another limitation is that at the time of 
data collection each enterprise was in a different 
phase of their ERP development life-cycle. Their 
challenges and problems were slightly different from 
each other. For instance, Case B faced challenges 
regarding parallel run and migration, because they 
were in the middle of implementation. Being at the 
beginning of the retirement phase, these challenges 


were not considered as the main problems in Case A. 
This difference is not only a limitation, but also 
enables richer categorization with variation in 
observation. 

6. Conclusion and future work 

With this study we increase the understanding of the 
concept of integration in ERP development by 
examining its obstacles. As a result of the analysis of 
empirical data, we identified 31 integration obstacles. 
Issues in intra-organizational environment, such as 
complicated end product and inexperience are the 
barriers for integration. The pressure from 
competitors and customer commitment in integration 
projects impose challenges. Technical barriers are 
related to integration product selection, and system 
development and configuration. In addition, the 
characteristics of the existing systems and the 
complexity of the IT infrastructure can further 
complicate the integration efforts. Integration requires 
management in order to be realized. Management 
from four levels, organizational, project, quality, and 
change management is needed to overcome the 
barriers of integration. We also identified the co mm on 
categories of ERP challenges from the literature. Our 
findings suggest that integration is tightly coupled 
with ERP development, and it should not be regarded 
as a single project activity, but rather as a continuous 
effort during the system life cycle. Finally, we 
provided practitioners with recommendations based 
on the lessons learned from our findings. 

The future research on integration obstacles should 
consider different domains and include also other 
organizations involved in ERP development besides 
the ERP adopters, such as vendors, consultants and 
business partners. In the future we aim to investigate 
the solutions to overcome the integration obstacles in 
different settings. 
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